
청구권 비교 분석의 에측 가능성을 위해서 Stage 1 결과물 생성을 동질화
(Stage 1 런타임: 7min 45secs --> 이전과 거의 동일)

오직 Stage 2의 LLM만 바꾸어가면서 실험

Prompt:
  - Stage 1:
  - Stage 2:

# 1st Try

LLM: Gemini 3.1 Pro
런타임: 4min 27secs
총비용: $2.93

## 청구권식별 퍼포먼스

C-001 -- 1
C-002 -- 10 (원고 강용원 빼야함)
C-003 -- 8
C-004 -- 2
C-005 -- 9 (원고 강용원 빼야함)
C-006 -- 3
C-007 -- 7
C-008 -- 6
C-009 -- 4
C-010 -- 11

청구권-사건종류 매칭 퍼포먼스:

청구권 식별 실수
- C-002, C-005: 원고에 강용원이 포함됨

청구권 잘못 식별
- 없음

청구권 식별 못함
- 인간 변호사의 **5. {"claim_title":"부당이득반환 청구","plaintiffs":["강용원"],"defendants":["박성희"],"claim_statement":"원고 강용원은 피고 박성희를 상대로 부당이득반환 청구를 할 수 있다."}**를 에이전트는 식별하지 못했음

청구권-사건종류 매칭 퍼포먼스:
- C-008: 에이전트는 "소유물방해제거·방해예방청구"라고 했으나 정답은 "토지인도 청구"

----------------------------------------------

## 2nd Try

LLM: GPT-5.4
런타임: 8min 15secs
총비용: $2.84

청구권식별 퍼포먼스:

C-001 -- 1
C-002 -- 9 (원고에 강용원 빼야함)
C-003 -- 10 (원고에 강용원 빼야함)
C-004 -- 3
C-005 -- 8
C-006 -- 11
C-007 -- 2
C-008 -- 7
C-009 -- 6
C-010 -- 5

에이전트가 청구권 식별 실수
- C-002, C-003: 원고에 강용원을 포함했음

에이전트가 잘못 식별한 청구권
- 없음

에이전트가 식별하지 못하고 놓친 청구권
- 인간 변호사가 식별한 청구권 **4. {"claim_title":"부당이득반환 청구","plaintiffs":["강용원"],"defendants":["이문호"],"claim_statement":"원고 강용원은 피고 이문호를 상대로 부당이득반환 청구를 할 수 있다."}**을 에이전트가 놓침 

청구권-사건종류 매칭 퍼포먼스:
- C-009: 에이전트는 "소유물방해제거·방해예방청구"라고 했으나 정답은 "토지인도 청구"


----------------------------------------------------------------


원인 분석에서 제시된 내용 중 "첫째, 평택시 빌라 쪽 C-003, C-005 문제는 원고적격을 좁힐 anchor가 약해서 생긴 것입니다. 실제 ..."와 "둘째, 성수동 대지 쪽 C-011 문제는 historical actor fixation이 아직 남아 있기 때문입니다. 최종 결과..."에 따르면 


"평택시 빌라의 원고적격 확정과 성수동의 현재 수익귀속 분리를 안정적으로 맞추려면, 결국 Stage 1→Stage 2 데이터 계약"을 보강하는 작업은 stage 1 프롬프트를 개선해야 하는 작업으로 보인다. 특히 "첫째, 평택시 빌라 쪽 C-003, C-005 문제는 원고적격을 좁힐 anchor가 약해서 생긴 것입니다. 실제 ..."에서 제시된 것처럼 원고적격을 좁힐 anchor를 강화하는 작업을 stage 1 프롬프트에 적용해야 할 것으로 보인다. 

Stage 1 프롬프트를 어떻게 개선해야 할지 반드시 필요한 작업 목록들만 제시하라. 


`최소 패치 4 — Stage 1 Task_A에 plaintiff_capacity_matrix, standing_watchpoints, current_control_map를 추가한다`와
`최소 패치 5 — Stage 1 Task_B2에서 current_state_candidate를 “점유자/사용자/수익귀속자/권리귀속자”로 분해한다`를 정확하게 반영하여 `Stage_1_new_updated.yaml`의 Task_A와 Task_B2 프롬프트를 개선하라. 작성한 프롬프트는 `Stage_1_new_updated.yaml`의 Task_A와 Task_B2 프롬프트를 copy and paste 형태로 replace 할 수 있도록 yaml 문법을 정확히 지켜서 작성하고 그것을 `stage_1_new_update_v2_A_B2.yaml`로 생성하라. 

지금 위에서 `최소 패치 4 — Stage 1 Task_A에 plaintiff_capacity_matrix, standing_watchpoints, current_control_map를 추가한다`와
`최소 패치 5 — Stage 1 Task_B2에서 current_state_candidate를 “점유자/사용자/수익귀속자/권리귀속자”로 분해한다`를 정확하게 반영하여 `Stage_1_new_updated.yaml`의 Task_A와 Task_B2 프롬프트를 개선하였다. 

개선된 Stage 1 프롬프트에 기반을 두고, 
`최소 패치 1 — Stage 2 Task_A 코드에서 evidence_indexed.json / evidence_event_candidates.json top-level unwrap를 반드시 넣는다`,
`최소 패치 2 — Stage 2 Task_A에 standing_context를 필수 projection으로 추가한다`,
`최소 패치 3 — Stage 2 Task_B에 “구제수단별 피고 선택 우선순위”와 “time-slice 분리”를 넣는다`를 정확히 반영하여 `Stage_2_updated_A_B_C_v1_gemini.yml`의 해당 프롬프트를 개선하라. 

작성한 프롬프트는 `Stage_2_updated_A_B_C_v1_gemini.yml`의 Task_A와 Task_B 프롬프트를 copy and paste 형태로 replace 할 수 있도록 yaml 문법을 정확히 지켜서 작성하고 그것을 `stage_2_new_update_v2_A_B.yaml`로 생성하라.


-------------------------------------------------------------


Stage 2 -- 업데이트 후 테스트
[4/12, 1:40pm] 
by 'Stage_2_updated_A_B_C_v1_gemini.yml' 

[주의]: 
- stage 1도 업데이트했으나 우선 stage 2 프롬프트만으로 테스트
- Workflow는 'Stage_1_new_updated.yaml' --> 'Stage_2_updated_A_B_C_v1_gemini.yml' 

## Gemini 3.1 Pro 버전 테스트
--> 추후 test 통과 시 common prefix를 stage 2 전체에 적용되면서 동시에 2,084 토큰 이상이 되도록 교체해야 한다 (API 비용 줄이기 목적)

## 식별 청구권 분석:
C-001 -- 1
C-002 -- X (강용원 -> 박광윤 부당이득반환청구)
C-003 -- 10
C-004 -- 11
C-005 -- X (강용원 -> 박광윤 건물인도청구)
C-006 -- 9
C-007 -- 8
C-008 -- 2
C-009 -- 3
C-010 -- 7
C-011 -- 6
C-012 -- 4
C-013 -- 5

## 에이전트 vs 인간 변호사 

에이전트가 청구권 식별 작업에서 실수한 것은 C-002, C-005

## 평가
- 원고 강용원 배제를 위해 [stage 1 -> stage 2] 데이터 전달 파이프라인 업데이트해야 함
- 이것은 업데이트한 stage 1 프롬프트를 실행하여 해결 가능할 것으로 보임
----------------------------------------------------------------

Stage 2 -- 업데이트 후 테스트
[4/12, 1:40pm] 
by 
  - 'Stage_2_updated_A_B_C_v1_gemini.yml'
                 ↓
  - 'Stage_1_new_updated_v1.yaml'

(주의: stage 1 & stage 2 모두 업데이트 버전으로 순차 실행)

## Gemini 3.1 Pro 버전 테스트
--> 추후 test 통과 시 common prefix를 stage 2 전체에 적용되면서 동시에 2,084 토큰 이상이 되도록 교체해야 한다 (API 비용 줄이기 목적)

## 테스트 기록
* stage 1
[런타임]: 6min 15secs
[총비용]: $1.30

* stage 2
[런타임]: 3min 15secs
[총비용]: $1.59

## 식별 청구권 분석:
C-001 -- 1
C-002 -- 2
C-003 -- 8
C-004 -- X (강용원->박광윤 부당이득반환청구)
C-005 -- 10
C-006 -- X (강용원->박광윤 건물인도청구)
C-007 -- 9
C-008 -- 3
C-009 -- 7
C-010 -- 6
C-011 -- 5
C-012 -- 11

## 평가
- 청구권 식별 실패
4. {"claim_title":"부당이득반환 청구","plaintiffs":["강용원"],"defendants":["이문호"],"claim_statement":"원고 강용원은 피고 이문호를 상대로 부당이득반환 청구를 할 수 있다."}

- 청구권 식별 실수
C-004, C-006: 원고 강용원 


[Stage 2만 GPT 버전으로 테스트]
[런타임]:
[총비용]: 
## 식별 청구권 분석:
C-001 -- 
C-002 -- 
C-003 -- 
C-004 -- 
C-005 -- 
C-006 -- 
C-007 -- 
C-008 -- 
C-009 -- 
C-010 -- 
C-011 -- 
C-012 -- 














-------------------------------------------------------------
Stage 2의 Task_B & Task_C 프롬프트가 연속작업 시 cache hit를 이용할 수 있도록 common prefix의 토큰 숫자가 2,048 tokens 이상되도록 재작성하라. 단, 토큰 숫자를 늘리기 위해서 군더더기를 만들어내서는 안된다. Stage 2 작업 내용 전체를 관통하는 공통의 prefix를 고안하고, LLM이 Task_B와 Task_C 작업 지시 내용을 정확히 이해하고, 그리고 그 지시사항을 효율적이고, 빠르고, 모든 작업 지시 내용을 정확히 수행할 수 있는 배경을 제공하는 의미에서 common prefix를 작성하라. 









